Most network communication protocols provide mechanisms by which recipients can acknowledge the receipt of information transmitted by senders. A lack of acknowledgements can indicate that transmitted information was lost between the sender and the recipient. Often the cause of such loss is network congestion. For example, network hardware, such as routers, can simply discard information if the information they are requested to handle exceeds their capacities. Therefore, senders can use acknowledgements, or lack of acknowledgements, to adjust the rate at which they transmit information. Continued acknowledgements indicate that the network has the capability to handle the current communication load, and, for the sake of efficiency, the sender can attempt to transmit information at an increased rate. Conversely, a lack of acknowledgements can indicate that the network was not able to properly handle the information that was transmitted, and the sender can attempt to transmit information at a reduced rate.
The ubiquitous Transmission Control Protocol and Internet Protocol (TCP/IP) used on many networks today provide mechanisms for ensuring the proper delivery of information, detecting congestion, and adjusting the rate at which senders transmit information. Both the Transmission Control Protocol and the Internet Protocol specify the format of headers that are attached to each packet of data. For example, TCP headers include identification information and various flags that can specify the type of packet. Similarly, IP headers include information specifying the sending and receiving devices as well as various flags that can provide information about the packet. To acknowledge receipt of a packet, a TCP-compliant recipient can form an acknowledgement packet that specifies the point in the data-stream until which it has received data. Such an acknowledgement packet has the ACK flag in the TCP header set and specifies the next expected sequence number in the byte-stream via the acknowledgement number in the TCP header. The acknowledgement packets can be used by the sending device to adjust the rate at which it transmits packets. For example, the sending device can decrease the rate at which it transmits packets if it has not received any acknowledgement packets for a predefined number of transmitted packets. Additionally, the sending device can decrease the rate at which it transmits packets if received acknowledgement packets continually indicating that some transmitted packets have not been delivered.
In addition to providing mechanisms by which delivered information can be acknowledged and the rate of transmitted information can be adjusted, TCP and IP also support mechanisms by which routers, and other devices that pass information along the network, can signal network congestion to the transmitting device, thereby enabling the device to preemptively reduce the rate at which it sends packets before packets are dropped and the device is forced to retransmit. Such mechanisms are known as Explicit Congestion Notification, or “ECN”. Sending and receiving devices supporting the ECN mechanisms can identify themselves as capable of understanding such congestion information by setting the ECN-Capable Transport (“ECT”) flag of the IP header. If a router, or similar device, is experiencing congestion, and it comes across a packet with the ECT flag set, the router can set a Congestion Experienced (CE) flag in the IP header prior to passing the packet along on its way to the intended recipient. Once recipient receives the packet, it can determine that the CE flag was set and, in the corresponding acknowledgement packet, the recipient can set the ECN Echo (ECE) flag in the TCP header. When the original sender receives the acknowledgement packet with the ECE flag set, it can take the prescribed steps to reduce the rate at which it transmits packets, and can signal this reduced state by setting the Congestion Window Reduced (CWR) flag in the TCP header.
Unfortunately, due to the quantity of devices that currently comprise networks such as the Internet, it is not feasible to expect that every device will employ the ECN mechanisms described above. However, unless every device along a communication path is ECN-compliant, the utility of the above-described mechanisms is greatly diminished. Specifically, if the congestion occurs at a router, or similar device, that is not ECN-compliant, that device will simply drop packets instead of setting the CE flag. Thus, packet loss can occur without the recipient ever receiving a packet with the CE flag set and without the recipient ever sending back an acknowledgement pack with the ECE flag set. Consequently, communicating devices are forced to implement transmission rate changes based on two different scenarios. Specifically, communicating devices that are ECN-capable can reduce their rate of transmission based on either: (1) receiving an acknowledgement packet with the ECE flag set or (2) receiving acknowledgement packets that implicitly indicate one or more dropped packets.
Therefore, what is needed is a mechanism by which congestion can be indicated to a transmitting device in a unified manner.